Complex software systems often include many source code resources that, through compilation, linking, and/or runtime actions, are loaded into memory and displayed in user interfaces. Typically, resources in a software project are isolated into resource files where resources are included and referenced or indexed by resource identifiers. The source code files in the software project include resources by referencing the necessary resource identifiers. For example, most user interface buttons have a label property. Source code might assign a resource identifier to a label of an instance of the button. The resource identifier may point to a localized resource string, e.g., “hello world”. When the source code is compiled and executed, the button is displayed with the “hello world” label. Using this layer of indirection for resources, it is convenient to change the locale (or language) for the resources for a software project. Usually, the resource strings are resolved at runtime. For instance, if an environment variable specifies a locality or language, that variable is used at runtime to select the resource file that will be used to resolve the resource strings.
Large software projects such as operating systems or complex web applications may have thousands or even millions of resource strings. Maintaining so many resource strings, for instance correcting errors or updating for consistency, is burdensome. If a software project is to be provided for different languages or locales, each different locale or language requires its own set of resource string translations or versions. Consider that there are over 7,000 languages spoken in the world. Roughly 150 to 200 of the world's languages are spoken by at least one million people. Yet even well-funded software projects with many decades of development often support no more than a hundred languages or dialects. As can be seen from these numbers, most software projects lack resource support for languages spoken by significant numbers of people. The practical inaccessibility of many software products means that much potential human productivity is unrealized.
One approach to this problem has been to enable communities of users to build or revise the resources of projects. With this approach, a feedback system is designed to allow users to provide feedback in association with a resource. Typically, workflows for such feedback have been limited to basic functions such as receiving a feedback from a user (e.g., a proposed edit or translation) and associating the feedback with the relevant software project or a generic screen or topic of the relevant software. Developers, translators, or editors then review the feedback and make appropriate edits or additions to the resources of the software project.
The current approach for managing feedback has many shortcomings. To make use of a feedback, a person (reviewer) must go through several steps. The feedback itself must be reviewed for accuracy and relevance. To review the feedback, and to apply it to a resource file, the reviewer must understand the context of the resource to which the feedback is directed. This may involve manual steps of tracking down the resource in source code, running the relevant software, using available clues to locate the resource. This alone can take significant time, even if the relevant user interface screen or application has been identified. Review of feedback such as a proposed resource addition or edit may involve verifying a proposed language translation or evaluating the propriety of a proposed change. This human involvement is costly and can slow down the time that it takes for feedback to be incorporated into a software project.
Techniques related to facilitating feedback for resource strings are discussed below.